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Abstract 

We  formalize  aspects  of  the  Kerberos  5  authentication 
protocol  in  the  Multi-Set  Rewriting  formalism  (MSR )  on  two 
levels  of  detail.  The  more  detailed  formalization  reflects  the 
intricate  structure  of  the  Kerberos  5  specification,  taking 
into  account  several  protocol  features  which  have  not  been 
previously  considered.  In  the  abstract  formalization,  we 
prove  an  authentication  property  about  Kerberos  5.  We  dis¬ 
covered  three  anomalies,  one  of  which  occurs  on  both  levels 
of  detail,  while  the  other  two  rely  on  the  richer  structure  of 
the  detailed  formalization.  We  also  discuss  how  the  addition 
of  checksums  (some  of  which  are  in  the  protocol  specifica¬ 
tion  and  some  of  which  are  not)  may  eliminate  some  of  these 
anomalies. 


1  Introduction 

Kerberos  [8,  10]  is  a  widely  deployed  protocol,  aimed 
at  repeatedly  authenticating  a  client  to  multiple  application 
servers  based  on  a  single  login.  Kerberos  makes  use  of  var¬ 
ious  tickets,  encrypted  under  a  server’s  key  unknown  to  the 
user,  which  when  forwarded  in  an  appropriate  request  au¬ 
thenticate  the  user  to  the  desired  service.  A  formalization  of 
Kerberos  4,  the  first  publicly  released  version  of  this  proto¬ 
col,  was  given  in  [5]  and  has  since  been  extended  and  thor¬ 
oughly  analyzed  using  an  inductive  approach  [1,  2,  3,  4], 
This  analysis,  through  heavy  reliance  on  the  Isabelle  theo¬ 
rem  prover,  yielded  formal  correctness  proofs  for  a  fairly 
detailed  specification,  and  also  highlighted  a  few  minor 
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problems.  A  simple  fragment  of  the  latest  version,  Ker¬ 
beros  5,  has  been  investigated  using  the  state  exploration 
tool  Mur<£>  [9].  This  approach  proved  effective  for  finding 
an  attack,  but  came  short  of  proving  positive  correctness 
results.  However,  the  authors  of  [9]  note  that  the  discov¬ 
ered  attack  is  unachievable  in  a  full  implementation  of  Ker¬ 
beros  5. 

We  have  recently  started  a  project,  the  goal  of  which  is 
to  use  the  Multi-Set  Rewriting  (MSR)  framework  to  give  a 
precise  specification  of  Kerberos  5  at  various  levels  of  de¬ 
tail,  ranging  from  the  minimal  account  used  in  [9]  to  a  de¬ 
tailed  formalization  of  every  behavior  encompassed  by  this 
complex  suite  [8,  10].  Our  objectives  include  giving  a  pre¬ 
cise  and  unambiguous  description  of  this  protocol,  making 
its  operational  assumptions  explicit,  stating  the  properties 
it  is  supposed  to  satisfy,  and  possibly  proving  them.  This 
will  complement  the  currently  spotty  and  often  vague  in¬ 
formation  in  the  literature.  This  project  is  also  intended  as 
a  test-bed  for  MSR  on  a  real-world  protocol:  we  are  inter¬ 
ested  in  how  easy  it  is  to  write  large  specifications  in  MSR, 
in  what  ways  this  language  can  be  improved,  and  whether 
the  insight  gained  with  toy  protocols  scales  up.  In  addition, 
we  have  started  exploring  forms  of  reasoning  that  best  take 
advantage  of  the  linguistic  features  of  MSR. 

This  paper  reports  on  preliminary  results  of  this  inves¬ 
tigation.  We  provide  two  formalizations  of  Kerberos  5. 
Our  abstract  description  omits  most  timestamps  and  all  op¬ 
tional  features,  including  only  what  we  believe  is  needed  to 
provide  authentication.  The  second  specification  includes 
several  low-level  aspects  of  this  protocol,  namely  options, 
flags,  checksums  and  error  messages,  none  of  which  have 
appeared  in  any  previous  study  of  Kerberos,  but  does  not 
include  temporal  checks  or  most  timestamps.  A  third  for¬ 
malization,  not  presented  here,  adds  some  timestamps  and 
temporal  checks  to  our  abstract  formalization.  We  do  not 
consider  timestamps  and  temporal  checks  in  this  paper  due 
to  the  thorough  treatment  of  them  in  [1,  2,  3],  space  consid- 
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erations,  and  the  fact  that  our  most  interesting  results  thus 
far  do  not  involve  temporal  properties.  We  are  currently 
working  to  extend  these  formalizations,  incorporating  the 
features  of  each,  to  give  additional  formalizations  which  are 
even  closer  to  the  full  protocol. 

We  have  proved  a  sample  of  the  expected  authentica¬ 
tion  properties  of  our  abstract  formalization  using  the  no¬ 
tion  of  rank  and  corank  functions,  inspired  by  [11],  It  ap¬ 
pears  that  this  technique  will  carry  over  to  proofs  of  other 
authentication  properties  of  our  abstract  formalization,  and 
also  corresponding  properties  of  our  more  detailed  formal¬ 
ization;  we  are  currently  pursuing  this.  Kerberos  is  specifi¬ 
cally  claimed  not  to  address  denial  of  service  attacks,  but  we 
found  three  other  anomalies  which  may  occur  when  using 
this  protocol.  The  first,  which  arises  in  both  formalizations 
presented,  violates  properties  that  were  proved  to  hold  for 
Kerberos  4  [1],  highlighting  the  structural  differences  be¬ 
tween  the  messages  in  versions  4  and  5  of  the  protocol.  The 
other  two  anomalies,  seen  only  in  our  more  detailed  formal¬ 
ization,  take  advantage  of  protocol  options  available  at  this 
level;  the  first  of  these  is  related  to  the  anomaly  seen  in  both 
formalizations  while  the  second  is  completely  unrelated. 

In  Sections  2,  3  and  4,  we  give  an  overview  of  the  Ker¬ 
beros  5  protocol,  the  MSR  formalism,  and  the  methods  we 
use  to  analyze  protocol  formalizations,  respectively.  Our 
abstract  formalization  is  discussed  in  Section  5,  its  intruder 
model  is  given  in  Section  6,  and  the  anomaly  at  this  level  is 
discussed  in  Section  7.  We  state  and  prove  authentication 
properties  inspired  by  [12]  in  Section  8.  Section  9  presents 
our  detailed  formalization  of  Kerberos  5,  while  the  corre¬ 
sponding  intruder  is  formalized  in  Section  10.  Section  11 
discusses  more  anomalies.  Finally,  Section  12  outlines  di¬ 
rections  for  future  work. 

2  Overview  of  the  Kerberos  5  protocol 

A  standard  run  of  Kerberos  5  consists  of  three  phases  in 
succession  outlined  in  Fig.  1  (please  ignore  the  details  in 
this  figure  for  the  moment).  Suppose  a  client  C  seeks  to 
authenticate  herself  to  a  particular  application  server  S. 

•  In  the  first  phase,  C  sends  a  request  KRB_AS_REQ  to  the 
Kerberos  Authentication  Server  (KAS)  K  for  a  ticket 
granting  ticket  TGT ,  for  use  with  a  particular  Ticket 
Granting  Server  (TGS)  T.  K  replies  with  a  message 
KRB_AS_REP  consisting  of  the  ticket  TGT  and  an  en¬ 
crypted  component  containing  a  fresh  authentication 
key  AKey  to  be  shared  between  C  and  T.  TGT  is 
encrypted  using  the  secret  key  kx  of  7  ;  the  accompa¬ 
nying  message  is  encrypted  under  C’ s  secret  key  kc- 

•  In  the  second  phase,  C  forwards  TGT,  along  with  an 
authenticator  encrypted  under  AKey,  to  the  TGS  T 
(message  KRB_TGS_REQ).  T  responds  in  KRB_TGS_REP 


by  sending  a  sen’ice  ticket  ST  encrypted  under  the  se¬ 
cret  key  ks  of  the  application  server  S,  and  a  compo¬ 
nent  containing  a  service  key  SKey  to  be  shared  be¬ 
tween  C  and  S,  encrypted  under  AKey. 

•  In  the  third  phase,  C  forwards  ST  and  a  new  authen¬ 
ticator  encrypted  with  SKey,  in  message  KRB_AP  JtEQ 
to  S.  If  all  credentials  are  valid,  this  application  server 
will  authenticate  C  and  provide  the  service.  The  ac¬ 
knowledgment  message  KRB_AP_REP  is  optional. 

A  single  TGT  can  be  used  to  obtain  several  service  tickets, 
possibly  with  several  application  servers,  while  it  is  valid. 
Similarly,  one  ST  can  be  used  for  repeated  service  from 
S  before  it  expires.  In  both  cases,  a  fresh  authenticator  is 
required  for  each  use  of  the  ticket. 

Note  that  such  a  protocol  run  described  above  is  very 
similar  to  that  of  Kerberos  4.  The  primary  difference  be¬ 
tween  the  two  versions  (aside  from  some  options  available 
in  version  5  and  not  in  version  4)  is  the  structure  of  the 
KRB_AS_REP  and  KRB_TGS_REP  messages.  In  version  4  the 
TGT  is  sent  by  the  KAS  as  part  of  the  message  encrypted 
under  the  client’s  secret  key  kc,  and  the  ST  sent  by  the 
TGS  is  likewise  encrypted  under  the  shared  key  AKey.  In 
version  5,  we  see  that  the  TGT  and  the  ST  are  sent  without 
further  encryption;  this  enables  the  cut  and  paste  anomalies 
which  we  describe  below. 

We  will  often  come  back  to  Fig.  1  as  we  formalize  differ¬ 
ent  aspects  of  Kerberos  5.  The  messages  and  fields  in  black 
will  constitute  our  abstract  specification  which  we  describe 
in  Section  5.  We  will  enrich  it  in  Section  9  with  the  parts  in 
gray  to  obtain  our  more  detailed  formalization. 

3  MSR 

MSR  originated  as  a  simple  logic -oriented  language 
aimed  at  investigating  the  decidability  of  protocol  analysis 
under  a  variety  of  assumptions  [7].  It  evolved  into  a  pre¬ 
cise,  powerful,  flexible,  and  still  relatively  simple  frame¬ 
work  for  the  specification  of  complex  cryptographic  proto¬ 
cols,  possibly  structured  as  a  collection  of  coordinated  sub¬ 
protocols  [6].  It  uses  strongly-typed  multiset  rewriting  rules 
over  first-order  atomic  formulas  to  express  protocol  actions 
and  relies  on  a  form  of  existential  quantification  to  sym¬ 
bolically  model  the  generation  of  nonces  and  other  fresh 
data.  It  supports  an  array  of  useful  static  checks  that  include 
type-checking  and  data  access  verification.  It  has  so  far 
been  applied  to  toy  protocols  such  as  Needham-Schroeder 
and  Neumann-Stubblebine  [6],  and  one  of  the  aims  of  this 
project  is  to  evaluate  it  on  a  real-world  protocol.  We  will  in¬ 
troduce  the  syntax  and  operations  of  MSR  as  we  go  along. 
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Client  (C) 


KAS  (K) 


TGS  (T) 


Server (S) 


KRB_AS_REQ 


KRB_AS_REP 


KRB .ERROR  -  AS 


— ►  Normal  messages 
-  ►  Error  messages 
— ►“  Application  messages 


* 


KRB_TGS_REQ 


KRB-TGS-REP 


KRB -ERROR  -  TGS 

KRB-AP-REQ 

-  • 

KRB -AP -REP 

KRB -ERROR  -  AP 

■M - 

Application  messages 

- ►- 

KRB-AS-REq  : 
KRB-AS-REP  : 
KRB_TGS_REQ  : 
KRB-TGS-REP  : 
KRB.AP-REQ  : 
KRB_AP_REP  : 
KRB -ERROR- X  : 


KOpts,C,  T,ni,e  TGT  =  {TFlags.AKey,  C}k 

C,  TGT,  {AKey,  m ,  T  Flags, T}%c  ST  =  {S  Flags, SKey,  C}fes 

TGT ,{C ,  MD,tc,Treq} AKey’T°Pts,C,S,n2,e  MD  =  [TOpts,  C,  S,n2,  e]AK 

C,  ST,  {SKey, n2,SFlags,SyAKey  MD '  =  [. .  ]s 

SOptS, ST,  { C ,  MD'  ,tc,Sreq} SKey 
{tC,Sreq}  SKey 

KRB  TERROR,  [—  \tc,Treq  \tc,Sreq\,  t(K  |T|S),ern  ErrCode,  C,  (A'|T|S) 


Figure  1.  Kerberos  5  Messages  in  the  Abstract  and  Detailed  Formalizations. 


3.1  Signature 

When  writing  a  specification  in  MSR,  one  decides  on  a 
logical  classification  of  protocol  entities  by  laying  out  ap¬ 
propriate  type  declarations.  The  signature  fragment  in  Fig¬ 
ure  2  sets  up  the  typing  infrastructure  in  the  case  of  Ker¬ 
beros  5.  The  types  used  in  this  paper  are  summarized  in 
the  central  column  of  the  following  table.  Italicized  types 
(e.g.,  ts  for  TGS  or  server,  and  tcs  for  ts  or  client)  are  aux¬ 
iliary  and  serve  the  purpose  of  making  precise  the  defini¬ 
tions  of  dbK  and  shK.  A  laxer  definition  could  do  with¬ 
out  them.  The  next  column  expresses  the  subtyping  rela¬ 
tion  corresponding  to  these  types  (r  : :  t'  means  that  r  is  a 
subsort  of  t').  Indentation  is  used  as  a  visual  aid  to  track 
dependencies.  The  declarations  shown  in  black  support  the 
abstract  formalization  of  this  protocol,  while  the  grayed-out 
additions  are  necessary  for  the  more  detailed  specification. 

Observe  that  shared  keys  (shK  _  _)  can  be  part  of  a  mes¬ 
sage,  but  database  keys  (dbK  _)  cannot.  Notice  also  that 
the  encryption  types  (needed  in  the  detailed  specification) 
parameterize  the  various  keys. 

The  syntax  of  messages  is  given  next.  The  first  two  dec¬ 
larations  formalize  concatenation  and  shared-key  encryp¬ 
tion  (possibly  using  different  algorithms,  as  specified  by  the 


encryption  types).  The  last  declaration  captures  message  di¬ 
gests  as  an  implementation  of  cryptographic  hashing.  They 
are  declared  similarly  to  shared-key  encryption. 


(Paring)  _  :  msg  — »  msg  — *  msg. 

(Encryption)  {_}  :  etype  — >  msg  — ■>  key  — >  msg. 
(Message  digest)  [_]-  :  etype  — >  msg  — ■>  key  — >  msg. 


We  will  keep  the  encryption  type  implicit  unless  we  are 
specifically  discussing  it  (as  in  Section  1 1.2).  In  our  present 
formalizations,  we  only  use  shared  keys  and  not  database 
keys  to  construct  message  digests. 

Additional  declarations  are  needed  to  populate  these 
types.  In  order  to  do  so,  we  declare  actual  clients,  servers, 
database  keys,  etc.  Conventional  names  for  various  meta¬ 
syntactic  entities  are  given  in  the  rightmost  column  of  Fig¬ 
ure  2.  For  example,  clients  will  typically  called  C.  An  un¬ 
derscore  in  a  name  will  be  appropriately  instantiated  in  the 
discussion:  for  example,  kc  will  represent  the  database  key 
of  a  client  C  and  tc,Sreq  will  stand  for  a  timestamp  issued 
by  C  to  make  a  request  to  S. 
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Types 

Subtyping 

Names 

( Messages ) 

msg  :  type. 

m,  X,  Y 

( Principals ) 

principal  :  type. 

principal  ::  msg. 

KAS  :  type. 

KAS  ::  principal. 

K 

tcs  :  type 

tcs  ::  principal. 

ts  :  type 

ts  ::  tcs. 

TGS  :  type. 

TGS  ::  ts. 

T 

server  :  type. 

server  ::  ts. 

S 

client  :  type. 

client  ::  tcs. 

C 

(Encryption  types) 

etype  :  type. 

etype  ::  msg. 

e 

(Keys) 

key  :  etype  — >  type. 
dbK  :  etype  — >  tcs  — >  type. 

Ve  :  etype, A  :  tcs.  dbKe  A  ::  keyc . 

k_ 

shK  :  etype  — >  client  — >  ts  — >  type. 

Ve  :  etype, C  :  client,  A  :  ts.  shKe  C  A  ::  keye . 

AKey 

Ve  :  etype, C  :  client,  A  :  ts.  shKe  C  A  ::  msg. 

SKey 

( Nonces ) 

nonce  :  type. 

nonce  ::  msg. 

n 

(Timestamps) 

time  :  type. 

time  ::  msg. 

t_,_ 

(Options) 

Opt  :  type. 

Opt  ::  msg. 

KOpt  :  type. 

KOpt  ::  Opt. 

KOpts 

TOpt  :  type. 

TOpt  ::  Opt. 

TOpts 

SOpt  :  type. 

SOpt  ::  Opt. 

SOpts 

(Flags) 

Flag  :  type. 

Flag  ::  msg. 

TFlag  :  type. 

TFlag  ::  Flag. 

TFlags 

SFlag  :  type. 

SFlag  ::  Flag. 

SFlags 

Figure  2.  An  MSR  Signature  for  the  Abstract  and  Detailed  Specifications  of  Kerberos  5 


3.2  State  and  Roles 

Intuitively,  MSR  represents  the  state  of  execution  of  a 
protocol  as  a  multiset  M  of  ground  first-order  formulas. 
Some  predicates  are  universal:  in  particular,  N(?n)  indi¬ 
cates  that  message  m  is  transiting  through  the  network. 
Other  predicates  are  protocol-dependent  and  are  classified 
as  memory  or  role  state  predicates.  Memory  predicates  are 
used  to  store  information  across  several  runs  of  a  protocol, 
to  pass  data  to  subprotocols,  and  to  invoke  external  mod¬ 
ules.  The  intruder  I  stores  intercepted  information  m  in  the 
predicate  I  (m).  We  will  encounter  other  memory  predicates 
as  we  go  along.  Role  state  predicates ,  of  the  form  L(. . .), 
allow  sequentializing  the  actions  of  a  principal. 

Principals  cause  local  transformations  to  this  global  state 
M  by  non-deterministically  executing  multiset  rewriting 
rules  of  the  form  r  =  Ihs  — >  rhs ,  where  Ihs  is  a  finite 
multiset  of  facts  and  some  number  of  constraints  (which  are 
not  facts).  These  constraints  are  used  by  principals  to  check 
system  clocks  or  determine  the  validity  of  requests  via  ex¬ 
ternal  processes  not  explicitly  modeled  here.  Whenever  the 
facts  in  Ihs  are  contained  in  M  and  the  constraints  are  all 
satisfied,  rule  r  can  replace  these  facts  with  those  from  rhs. 
The  actual  definition  is  slightly  more  general  in  the  sense 
that  rules  are  generally  parametric  and  rhs  may  specify  the 
generation  of  nonces  or  other  data  before  rewriting  the  state. 

The  rules  comprising  a  protocol  or  a  subprotocol  are  col¬ 
lected  in  a  role  parameterized  by  the  principal  executing  it. 
Rules  in  a  role  are  threaded  through  using  role  state  predi¬ 


cates  declared  inside  the  role. 

4  Protocol  Analysis  Methods 
4.1  Overview  of  rank  and  corank 

Inspired  by  Schneider’s  analysis  of  the  amended 
Needham-Schroeder  protocol  [11],  we  define  rank  and 
corank  functions  on  (multisets  of)  facts. 

Our  definition  of  fc-rank  relative  to  mo  is  intended  to 
capture  the  maximum  number  of  nested  encryptions  of  the 
message  mo  under  the  key  k  which  appear  in  a  fact.  We  ad¬ 
ditionally  require  that  the  innermost  encryption  be  exactly 
{m0}k.  We  use  rank  to  authenticate  the  origin  of  {mo}fc  by 
showing  that  a  particular  principal  may  create  a  message  of 
/.-rank  1  relative  to  ro0  and  that  no  other  principals,  includ¬ 
ing  the  intruder,  can  increase  the  rank  of  facts. 

The  /i'-coranl<  of  relative  to  mo  is  intended  to  capture  the 
minimum  number  of  decryptions,  using  keys  from  E,  that 
must  be  performed  in  order  to  extract  mo  from  a  fact.  We 
use  corank  to  prove  the  secrecy  of  m o  by  showing  that  no 
facts  of  .E-corank  0  relative  to  mo  can  ever  appear  in  the 
multisets  in  a  trace. 

The  definitions  of  rank  and  corank  of  messages  and  facts 
are  given  below;  we  do  not  define  rank  and  corank  for  con¬ 
straints  since  these  are  not  facts.  We  are  optimistic  that 
the  notions  of  rank  and  corank  and  the  corresponding  proof 
techniques  can  be  easily  extended  and  exported  to  the  MSR 
formalizations  of  other  protocols. 
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Pk(m;m0 ) 


'0, 

jOfe(TOi;m0)  +  1, 

0, 

1, 

pfc(mi;m0), 

max{ft(mi;  m0),pk(m2\  m0)}, 


to  is  an  atomic  message 

to  =  {TOi}fc,  pk{m i;  too)  >  0 

to  =  {TOi}fc,  pk(mi;  too)  =  0,  toi  ^  ?n0 

{TOo}fe 

to  =  {mi}fc/,  k'  ^  k 
to  =  mi  ,  ?ri2 


Figure  3.  Definition  of  relative  /c-rank  on  messages. 


pE(m;m0)  =  < 


oo, 

0, 

PS(toi;to0)  +  1, 
/5_e(toi;too), 


m  is  atomic,  m  ^  Too 
m  =  mo 

m  =  {mi}k  ^  mo,  k  £  E 
m  =  {m\}k  ±  mo,  k  ^  E 


min{pB(mi;  m0), p_e(to2;  to0)},  to  =  (mi, to2)  toi, to2  7^ 


Figure  4.  Definition  of  relative  P-corank  on  messages. 


4.2  The  /c-rank  relative  to  m0 


4.3  The  P-corank  relative  to  m0 


We  define  a  function  pk(rn:  Too),  the  /c-rank  of  a  mes¬ 
sage  to  relative  to  a  fixed  message  ?no,  which  we  will  use 
to  prove  properties  about  the  origin  of  data.  If  a  message  to 
appears  on  the  network  with  pk{m;  mo)  =  i  >  0  and  the 
intruder  is  unable  to  increase  the  /c-rank  of  messages  rel¬ 
ative  to  mo,  then  this  message  originated  with  some  other 
principal.  Since  the  other  principals  are  well-behaved  (all 
malicious  activity  is  done  by  the  intruder),  we  may  then  be 
able  to  make  a  statement  about  the  origin  of  the  message  to. 
Formally,  for  a  fixed  nonzero  too  :  msg,  any  key  k,  and  any 
to  :  msg  we  define  pk(m\  mo)  as  in  Fig.  3. 

We  extend  the  the  definition  of  /c-rank  relative  to  mo  to 
facts  as  follows.  For  to,  to.  1, . . . ,  rrij  :  msg,  P  a  role  state 
or  memory  predicate  (other  than  I  or  N)  of  arity  j,  and  k'  a 
database  key,  make  the  following  definitions. 


pk(N(m);m0) 
Pit  (I  (to);  to0) 
pk{\{k')\mo) 
Pk(P(mi, . . . ,  mj);  to0) 


=  pk{m\  m0)  (1) 

=  pk(m;m0)  (2) 

=  0  (3) 

=  max  ft(mi;m0)  (4) 

i<*<y 


We  then  define  the  /c-rank  relative  to  too  of  a  multiset  A  of 
finitely  many  distinct  facts  as 


Pk(A;  too)  =  max  pk(F;  m0 ).  (5) 

FeA 

A  rule  r  which  has  the  multiset  A  on  its  left  hand  side  and 
the  multiset  B  on  its  right  hand  side  is  said  to  increase  (resp. 
preserve,  decrease)  /c-rank  relative  to  mo  if  pk(B\mo)  > 
Pk{A-,mo)  (resp.  =,  <).  We  use  weakly  increase,  etc.,  in 
the  usual  manner. 


While  the  /c-rank  relative  to  too  will  be  useful  in  proving 
properties  about  the  origin  of  data,  we  turn  to  an  intuitively 
dual  notion,  that  of  A'-coranl<  relative  to  a  message  mo, 
to  prove  things  about  secrecy.  We  require  that  too  cannot 
be  written  as  mi,  m2  for  two  nonempty  messages  toi,  to2. 
Formally,  we  define  the  A'-coranl<  of  in  relative  to  too  as  in 
Fig.  4. 

We  extend  corank  to  facts  and  multisets  of  facts  in  a 
slightly  different  way  than  we  do  for  rank.  Since  corank 
is  intended  to  capture  the  minimum  work,  with  respect  to 
a  set  E  of  keys,  needed  to  obtain  a  secret  too,  we  need  to 
take  care  when  considering  decryption  by  principals.  If  a 
principal  decrypts  a  message  to  obtain  the  secret  mo  and 
stores  too  in  a  predicate  but  never  sends  mo  over  the  net¬ 
work,  encrypted  or  otherwise,  this  action  by  itself  should 
not  mean  we  view  too  as  accessible  without  further  de¬ 
cryption  using  keys  from  E.  For  a  predicate  P  of  arity 
j,  we  thus  do  not  want  to  define  the  A-corank  relative  to 
mo  of  P(toi,  . . . ,  mj)  to  be  the  minimum  of  the  relative 
A'-coranks  of  P’s  arguments,  but  rather  the  minimum  over 
those  which  might  ever  go  back  onto  the  network.  For  the 
moment,  we  make  the  following  definitions  using  this  idea 
as  a  guide  and  do  not  give  a  formal  definition  of  the  relative 
P-corank  of  a  general  predicate  P. 

For  a  fixed  mo  '■  msg  and  to,  to*  :  msg,  L  a  role  state 
predicate  of  arity  j,  k!  a  database  key,  define  the  P-corank 
of  facts  relative  to  too  as  follows. 

Ae(N(to);  too)  =  /5e(to;to0) 
ps (I (to.);  too)  =  Pe(to;  to0) 
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pE  ( Authc  ( mi ,  m2 ,  m3 ,  m4) ;  m0) 
pE  ( Ser  vicec  (toi ,  m2 ,  m3 ,  m4 ) ;  m0 ) 
ps(L(mi, ...  m0) 

pE{DoneMwtc{m,\,nn2 );  mo) 
PE (M ems (mi,  m2,  m3 ) ;  to0) 

pE(l(fc');TO0) 


Pb(toi;to0) 

Pb(toi;to0) 

OO 


OO 

OO 

OO 


We  may  then  define  the  E -corank  relative  to  mg  of  a 
multiset  A  of  finitely  many  distinct  facts  as 


pa  (A;  too)  =  min  /3fc(F;  to0). 
FeA 


(6) 


5  Abstract  Level  Protocol  Formalization 


In  this  section  we  give  our  abstract  formalization  of  the 
protocol.  The  MSR  rules  corresponding  to  each  exchange 
here  are  depicted  in  Figs.  5 — 10.  Portions  of  these  fig¬ 
ures  are  grayed  out;  the  dark  type  represents  our  abstract 
level  rules,  and  the  grayed  portions  will  be  ignored  for  now. 
When  we  refer  to  an  abstract  level  rule  by  name,  we  shall 
use  an  <2  with  an  appropriate  subscript,  given  in  the  figures 
in  dark  type  over  each  arrow. 

We  believe  that  this  formalization  contains  the  minimum 
amount  of  detail  needed  to  capture  the  Kerberos  5  proto¬ 
col.  Although  we  do  not  directly  use  the  nonces  in  the  lem¬ 
mas  and  proofs  given  here,  omitting  them  would  remove  the 
connection  between  the  KRB_AS_REQ  and  KRB_AS_REP  mes¬ 
sages. 

5.1  Authentication  Service  Exchange 

Recall  that  the  Authentication  Service  Exchange  allows 
a  client  C  to  obtain  from  a  KAS  K  credentials  to  be  used  in 
the  Ticket  Granting  Exchange  with  a  TGS  T.  C’s  actions  in 
this  exchange  are  formalized  in  Fig.  5,  K ’s  in  Fig.  6. 

C  asks  K  for  credentials  for  the  server  T  using  rule  <21.1, 
sending  a  KRB_AS  JtEQ  message  with  her  name  C,  the  name 
T  of  the  TGS  for  which  she  wishes  to  obtain  credentials, 
and  a  fresh  nonce  ni,  and  storing  these  in  the  role  state 
predicate  L.  Rule  <21.2  allows  C  to  process  the  KRB_AS_REP 
message  which  K  sends  in  response  to  her  initial  request. 
This  message  is  expected  to  contain  C’s  name,  an  opaque 
ticket  X  to  be  passed  on  to  T,  and,  encrypted  under  C s 
long-term  key  kc ,  a  session  key  AKey  for  use  with  T,  the 
nonce  n  1  from  the  original  request,  and  the  name  T  of  the 
TGS.  If  the  message  is  of  this  form  and  if  C,  T,  and  n\, 
match  the  data  from  the  original  request  (stored  in  L ),  C  re¬ 
moves  the  KRB_AS_REP  message  from  the  network,  deletes 
the  role  state  predicate  L,  and  stores  the  relevant  data  in  the 
persistent  memory  predicate  Authc ■  Ft  the  abstract  formal¬ 
ization,  C  does  not  process  any  other  (i.e.,  error)  messages 
which  I\  may  return  as  defined  in  [10]. 


If  there  is  a  KRB_AS_REQ  message  from  C  on  the  net¬ 
work,  and  if  it  is  valid  (as  determined  by  the  external  pro¬ 
cess  Valid),  rule  a2.i  allows  K  to  generate  a  fresh  session 
key  AKey  for  use  between  G  and  T  and  to  send  this  key  in 
a  KRB_AS_REP  message  to  C.  This  message  consists  of  C's 
name,  the  ticket  for  T,  and,  encrypted  under  kc,  the  key 
AKey,  the  nonce  n\  from  C’s  request,  and  the  name  T  of 
the  TGS.  The  ticket  for  T  is  encrypted  with  T’s  long-term 
key  kx  and  contains  AKey  and  the  name  C  of  the  client. 

5.2  The  Ticket-Granting  Exchange 

The  third  and  fourth  messages  shown  in  dark  type  in 
Fig.  1  comprise  the  Ticket-Granting  Exchange.  Here  the 
client  C  presents  credentials  previously  obtained  from  an 
authentication  server  (via  the  Authentication  Service  Ex¬ 
change)  to  a  TGS  T  in  order  to  obtain  a  service  ticket  for  an 
application  server  S. 

The  client’s  actions  in  this  exchange  are  formalized 
in  Fig.  7.  If,  as  indicated  by  the  memory  predicate 
Authc  (X,T,  AKey),  the  client  C  has  completed  the  au¬ 
thentication  service  exchange  to  get  credentials  for  the  T GS 
T,  rule  031  allows  her  to  initiate  an  exchange  with  T  to 
obtain  credentials  for  the  application  server  S.  In  doing  so, 
she  chooses  a  new  nonce  n2  and  sends  a  KRB_TGS_REQ  mes¬ 
sage  to  T  consisting  of  the  previously  obtained  ticket  X,  an 
authenticator  (C  encrypted  under  the  session  key  AKey), 
her  name  C,  the  name  S  of  the  server  for  which  C  wishes 
to  obtain  credentials,  and  the  new  nonce  n2.  C  stores  the 
information  about  this  request  in  the  role  state  predicate  L, 
and  retains  the  memory  predicate  Authc  for  use  in  future 
exchanges  with  T. 

The  client’s  second  rule,  <23.2,  allows  her  to  read  from  the 
network  a  KRB_TGS_REP  message  that  matches  her  request 
to  T.  This  message  consists  of  C’s  name,  an  opaque  ticket 
Y  to  be  passed  to  the  application  server,  and,  encrypted  un¬ 
der  the  session  key  AKey,  a  session  key  SKey  for  use  by 
C  and  the  application  server,  the  nonce  n2,  and  the  applica¬ 
tion  server’s  name  S.  C,  S,  and  n2  must  match  the  stored 
information  about  the  original  request  to  T  in  order  for  C 
to  process  the  KRB_TGS_REP  message.  If  C  does  process  the 
message  using  <23.2,  she  stores  the  ticket  Y,  server  name  S, 
and  session  key  SKey  in  the  memory  predicate  Servicec- 

Fig.  8  shows  the  actions  of  the  TGS  T  in  the  Ticket 
Granting  Exchange.  The  rule  <241  allows  T  to  process  a 
valid  KRB_TGS_REQ  message  and  send  a  KRB_TGS_REP  reply 
containing  credentials  for  C  to  use  with  S.  The  request  on 
the  network  must  contain  a  ticket  ( AKey  and  C  encrypted 
under  T’s  secret  key  hr),  an  authenticator  with  C’s  name 
encrypted  under  the  key  from  the  ticket,  the  client’s  name 
C,  the  server’s  name  S,  and  a  nonce  n2.  If  the  message  is 
of  the  correct  form  and  is  valid  (as  determined  by  the  exter¬ 
nal  process  V alid),  then  T  may  reply  with  credentials  for 
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/  3L  :  client  x  KOptxTGS  X  noncexetype. 


VCrclient 


\ 


VT  :  TGS 

WK  :  KAS 

VKOpts  :  KOpt. 

Ve  :  etype 

aS  1.1 

3ni  :  nonce 

N (KOpts, C,  T,m,e) 

L(C,  KOpts, T,  ni ,  e) 

V... 

Vkc  :  dbK  C 
MAKey  :  shK  CT. 
\/X  :  msg 

Vni  :  nonce 

VT  Flags  :  TFlag  . 

N(C,  X,  {AKey, 
m,TFlags,T}kc) 

L(C ,  KOpts.T ,  n\ ,  e) 

aS  1.2 

Authc(X,  T Flags, 

T,  AKey ) 

V... 

WErrorCode  :  msg. 
\VtK,err  '•  time 

N(KRB .ERROR, 

ErrorCode ,  C,  K ) 
L(C ,  KOpts ,  T,  ni ,  e) 

<5l.2' 

AS  Error  c  (KRB  .ERROR, 
t-K,em  ErrorCode ,  K) 

Figure  5.  The  client’s  role  in  the  Authentication  Service  Exchange. 


/VC  :  client 
VT  :  TGS 
Vni  :  nonce 

\/kc:dbKC  .  N (KOpts, C,  T,  m,  e) 

\/kT  :  dbK  T  .  ValicL(KOpts,C,T,  ni,  e) 
\/AKey  :  shK  C  T.  SetAuthFlags(KOpts,TFlags) 
VKOpts  :  KOpt  . 

Ve  :  etype 
MTFlags  :  TFlag  . 


\ 


VifiKAS 


3  AKey  :  shK  CT 
N(C,{TFlags.AKey,C}krr, 
{AKey,n\,T  Flags, T}kc) 


V... 

ErrorCode  :  msg. 
V  Vtx  err  :  time 


H(KOpts,C,  T,  ni,  e) 
Invalid{KOpts ,  C,  T,  ni ,  e) 
Clock k  {t  K  ,err) 


N(KRB .ERROR,  tj^err, 
ErrorCode ,  C,  X) 


Figure  6.  The  authentication  server’s  role  in  the  Authentication  Service  Exchange. 


C  to  use  with  S.  To  do  so,  T  generates  a  new  session  key 
for  use  by  C  and  S  and  constructs  a  ticket  for  S  contain¬ 
ing  this  key  and  C’s  name  and  encrypted  under  S’ s  secret 
key  ks-  T  then  sends  a  network  message  consisting  of  C’s 
name,  the  ticket  for  S,  and,  encrypted  under  the  session  key 
AKey  that  T  shares  with  C,  the  session  key  SKey  for  use 
by  C  and  S,  the  nonce  from  C’s  request,  and  the  name  of 
the  server  S.  T  does  not  send  any  error  messages  in  this 
level  of  abstraction. 

5.3  The  Client/Server  Authentication  Exchange 

The  fifth  and  sixth  messages  in  dark  in  Fig.  1  form  the 
Client/Server  Authentication  Exchange.  Here  the  client  C 
presents  credentials,  previously  obtained  from  a  TGS,  to  the 
application  server  S.  In  the  abstract  level  formalization  we 
assume  that  mutual  authentication  is  requested  by  C;  thus 
the  sixth  message  (of  type  KRB_AP_REP)  is  required  for  the 
protocol  to  finish. 

Fig.  9  shows  the  role  of  the  client  C  in  the  exchange. 
If  she  has  previously  obtained  credentials  (a  ticket  Y 
and  session  key  SKey,  stored  in  the  memory  predicate 
Servicec )  for  use  with  S  she  may  fire  rule  a^.i-  This 


places  a  KRB_AP_REQ  message  containing  the  ticket  and  an 
authenticator  (obtained  by  encrypting  C  and  the  current 
time  tc,Sreq  °n  C’s  system,  given  by  the  external  process 
Cloche,  under  the  session  key  SKey)  on  the  network  and 
stores  the  relevant  information  about  this  request  in  the  role 
state  predicate  L.  C’s  second  rule,  015,2,  may  be  fired  when 
the  network  contains  a  KRB_AP_REP  message  consisting  of 
tc,Sreq  encrypted  under  SKey.  This  rule  reads  the  message 
from  the  network  and  stores  the  server  name  S  and  the  ses¬ 
sion  key  SKey  in  the  the  DoneMutc  predicate.  Although 
not  modeled  in  the  abstract  level  formalization,  this  infor¬ 
mation  is  intended  to  be  used  in  additional  communications 
with  S. 

The  server’s  role  in  this  exchange  is  given  in  Fig.  10. 
If  the  network  contains  a  valid  (as  determined  by  the  ex¬ 
ternal  process  Valid)  KRB_AP_REQ  message  consisting  of 
a  ticket  {SKey,C}ks  encrypted  under  S’ s  secret  key  ks 
and  a  matching  authenticator  {C,  tc,Sreq} SKey’  &  may  Pro" 
cess  the  request  by  firing  rule  o:fi  | .  This  reads  the  message 
from  the  network  and  replies  with  the  timestamp  tc,Sreq  en¬ 
crypted  under  the  session  key  SKey  from  the  ticket.  Note 
that  in  this  formalization,  we  are  essentially  using  tc,Sreq 
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/  3L  :  client  x  TOptxserver  x  TGS  x  noncextime. 


VC:client 


\ 


VT  :  TGS 

VS  :  server 

WAKey  :  shK  CT. 
WX  :  msg 

VtC,Treq  ■  time  . 
\/TFlags  :  TFlag  . 
WTOpts  :  TOpt 

Ve  :  etype 

Authc{X,  TFlags.T,  AKey ) 
Clockc(tc,Treq) 

c*53.i 

3ri2  :  nonce 

N(X,  {C,  [TOpts,  C,  S,  n2,e\AKey, 
tC,Treq}AKey’  TOpts. C,  S,  712,  e) 
Authc(X,  TFlags,T,  AKey) 

L(C,  TOpts, S,  T,  712 ,  tc,Treq ,  e) 

V... 

VS  Key  :  shK  C  S. 
VY  :  msg 

Vri2  :  nonce 
VSFlags  :  SFlag  . 

N  (C,Y, 

{SKey,n2,  SFlags, S}AKey) 
L(C,  TOpts, S,  T,  n 2,  tc,Treq,  e) 

<*£3.2 

Servicec(Y,  SFlags, 

S,  SKey) 

V... 

VErrorCode  :  msg. 
\VtT,err  ■  time 

NfKRB _ERR0R,  tc,Treq>  tT,em 
ErrorCode,  C,  T) 

L{C ,  TOpts,  S,  T,  U2,tc,Treq,  e) 

£3.2' 

TGSErrorc(T,  tq  err,  ErrorCode) 

/ 

Figure  7.  The  client’s  role  in  the  Ticket-Granting  Exchange. 


f'iC  :  client 
VS  :  server 
MAKey  :  shK  CT 
VfcT  :  dbK  T 
Vfcs  :  dbK  S 
Vn2  :  nonce 
Vtc,Treg  :  time 
VTOpts  :  TOpt 
Ve  :  etype 
VSFlags  :  SFlag 
Vck  :  msg 
VTFlags  :  TFlag 


N({T  Flags,  AKey,C}kT, 

{C.ck,  tc.Treq} AKey’ 

TOpts, C,  S,  ri2,  e) 
Valid(TOpts,C ,  S ,  712,  e,  tc,Treq) 
SetServFlagsfTOpts,  SFlags) 
ck  =  [TOpts,  C,  S,  U2,  e\AKey 


\  VT:TGS 


3SJVer/  :  shK  C  S 

N(C,  {SF«ags,S/Vey,  C}ks , 

{SKey,n2,  SFlags, S}AKey) 


V 


V... 

VErrorCode  :  msg. 
V^T,err  :  time 


N({TF/ags,AJVei/,C}fcr, 
{C,  Cfc,  tc,Treq} AKey’ 

T Opts  ,C,S,n 2 ,  e) 
Invalid(TOpts,  C,  S,  n,2, 
e,  tc,Treq’ck ) 

Clocks  {t-T ,  err) 


N  (KRB -ERROR,  tc,Treq  5  ^T,err  5 
ErrorCode ,  C,  T) 


Figure  8.  The  ticket  granting  server’s  role  in  the  Ticket  Granting  Exchange. 


as  a  nonce;  no  temporal  checks  are  performed  on  it,  but 
this  reply  is  intended  to  authenticate  S  to  C.  The  server  S 
also  remembers  the  relevant  data  from  the  request  for  future 
communication  with  C  and  to  guard  against  replay  attacks, 
although  neither  of  these  uses  is  modeled  in  this  formaliza¬ 
tion. 

6  Abstract  Level  Intruder  Formalization 

In  this  section,  we  present  the  rules  specifying  the  Dolev- 
Yao  intruder  model  for  Kerberos  5.  We  ask  the  reader  to 
ignore  for  the  moment  the  grayed-out  text  as  it  describes 
additions  needed  for  the  more  detailed  intruder.  We  will 
come  back  to  them  in  Section  10. 

We  divide  the  actions  available  to  the  intruder  into  three 


categories: 

•  the  fairly  standard  operations  of  intercep¬ 
tion/transmission  of  a  message  over  the  network, 
decomposition/composition  of  a  pair,  and  decryp¬ 
tion/encryption  of  a  message  given  a  known  key 
(Section  6.1); 

•  the  often  overlooked  action  of  generating  new  data 
(Section  6.2); 

•  and  the  use  of  accessible  data  (Section  6.3). 

6.1  Network,  Pairing  and  Encryption  Rules 

We  have  the  following  rules  describing  how  the  Dolev- 
Yao  intruder  can  intercept/transmit  messages,  decom- 


3L  :  client^)  x  SO  ptx  server^)  x  shK  C  S  x  time  x  i 


VS  :  server 
VS  Key  :  shK  C  S 
Vtc,Sreq  ■  time 
VY  :  msg 
MSFlags  :  SFlag 
MSOpts  :  SOpt 


Servicec(Y,  S  Flags. S,  SKey) 
Mutual  (S  Opts ) 

Clockgg  (tgjSreq) 


N({t-c,Sreq}  SKe  y) 

L(C,  SOpts,S,  SKey,  tc,Sreq ,  Y) 

V.  ..  .  N(KRB_ERROR,  tc,Sreq, 

M  ErrorCode  :  msg.  ts  err,  ErrorCode,  C,  S) 

Mts, err  '■  time  .  L(C,  SOpts,  S,  SKey,  tc,Sreq,Y) 


N (SOpts, Y,  {C,  [.  .  •] SKeytc,Sreq} SKey) 
ServiceciY. ,  SFlags,S,  SKey) 

L(C,  SOpts,S,  SKey,  tc,Sreq,Y) 


DoneMutc{S,  SKey) 


APErrorc(S,  tg  err >  ErrorCode) 


Figure  9.  The  client’s  role  in  the  Client/Server  Exchange  with  mutual  authentication. 


(MC  :  client 
MS  Key  :  shK  C  S 
MtC,S req  ■  time 
Mks  :  dbK  S 
Mck  :  msg 
MSOpts  :  SOpt 
MSFlags  :  SFlag 


N (SOpts, {SFlags, SKey,  C}ks , 
{C,  ck,tc,Sreq} SKey) 

Mutual  (SOpts) 

Valid(C,  SOpts,  SFlags,tc,Sreq) 
ek  —  f. .  .1  c  zs — 


N(SOpts,  {SFlags,  SKey,  C}ks , 
y  {O',  ck,  tc,Sreq} SKey) 

MErrCode  :  msg!  Mutual(SOpts) 
v.  .  ti  Invalid(C,  SOpts, 

SFlags,  SKey,  tc,Sreq,  ck) 
Clocks  {ts,err) 


N({tC,Sreq}gifej/) 

Mems(C,  SKey,  tc,Sreq) 


N(KRB .ERROR,  tc ,Sreqi 
ts,err->  ErrCode ,  C ,  S) 


Figure  10.  The  end  server’s  role  in  the  Client/Server  Exchange  with  mutual  authentication. 


pose/compose  pairs,  and  decrypt/encrypt  messages  under 
the  various  types  of  known  keys.  We  have  also  some  ad¬ 
ministrative  rules  that  permit  the  duplication  and  deletion 
of  deleted  data. 

The  following  two  rules  model  interception  (INT)  and 
transmission  (TRN): 


(Vm  :  msg.  N(m) 
(Vm  :  msg.  I (m) 


N(m)) 


The  following  two  rules  model  decomposition  (DMC) 
and  composition  (CMP): 


/VC  :  client  \ 

MA:  ts  .  ,e. 

Me  :  etype  .  Sh>  — »  l(m) 

Vfe  :  shKe  C  A.  w 
\Mm  :  msg  .  J 

/ VC  :  client  \  1 

MA:  ts  .  .  . 

Ve:  etype  .  ^  ^  I {{m}%) 

Mk  :  shK'  C  A.  y  > 

\Mm  :  msg  .  J 

The  following  two  rules  model  decryption  (DDC')  and 
encryption  (DEC')  with  a  long  term  (database)  key: 


Mm\,mi  :  msg.  l(mi,W2) 


w  I  (rrzi )  cmp 

Vmi, m2  :  msg.  j  — ♦  I(mi,m2, 


The  following  two  rules  model  decryption  (SDC')  and 
encryption  (SEC')  with  a  shared  key: 


M A  :  tcs 
Me  :  etype 
Mk  :  dbK'  A 
Mm  :  msg 

MA  :  tcs 
Me  :  etype 
Mk  :  dbK  A 
Mm  :  msg 


K  {m}%)  ddc; 


I  ( m )  DEC' 
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We  conclude  with  the  some  administrative  rules  that  al¬ 
low  the  intruder  to  duplicate  known  data  (DPM  and  DPD) 
and  to  forget  information  (DLM  and  DLD),  for  both  mes¬ 
sages  and  database  keys.  The  deletion  form  can  safely  be 
omitted  from  the  specification. 


I(_)  predicate  to  mount  attacks.  The  intruder  therefore  has 
access  to  the  name  of  any  principal,  to  its  own  keys  (both 
long-  and  short-term),  and  to  timestamps. 

Access  to  a  generic  principal  name  (possibly  a  client,  a 
server,  a  TGS  or  a  KAS)  is  handled  by  the  following  rule: 


Vm  :  msg.  I (m) 


I  (m)\ 
I  My 


(Vm  :  msg.  I (m) 
/VA  :  tcs 

Ve  :  etype  .  I(/ca) 
\VkA  :  dbK':  A. 


KM  J 


Pi  A  :  tcs 

I  Ve  :  etype  .  I (kA) 
\VkA  ■  dbK'  A. 


6.2  Data  Generation  Rules 


As  a  rule,  the  intruder  should  be  able  to  generate  every¬ 
thing  an  honest  principal  can  generate,  in  our  case  nonces 
and  session  keys,  and  no  more.  In  the  case  of  Kerberos, 
we  must  admit  an  exception  to  this  rule:  since  principals 
forward  uninterpreted  data,  we  must  allow  the  intruder  to 
create  garbage,  modeled  as  objects  of  the  generic  type  msg. 

The  rules  for  generating  nonces  (NG)  and  session  keys 
(KG')  are  as  follows: 

(  •  3 n  :  nonce  l(n)) 


(VA  :  principal.  •  1(A)) 

The  next  rule  below  gives  the  intruder  access  to  any  de¬ 
fined  timestamp.  This  makes  objects  in  this  syntactic  cate¬ 
gory  guessable  and  in  this  regard  different  from  nonces. 

(Vf  :  time.  •  -M  I (t )) 

The  intruder  is  entitled  to  lookup  any  session  key  he 
owns.  This  is  modeled  by  the  following  two  slightly  asym¬ 
metric  rules. 

Pi  A  :  ts 
Ve  :  etype 
\Vk  :  shK'  I  A. 

VC  :  client 
Ve  :  etype 
Vk  :  shK  Cl. 

It  should  be  possible  to  prove  that  these  rules  are  redundant 
since  the  intruder,  like  any  other  principal,  is  handed  its  ses¬ 
sion  keys  by  the  KAS  or  the  TGS.  Therefore,  these  rules 
could  be  eliminated. 

Finally,  we  have  the  following  rule  describing  how  the 
intruder  access  his  long-term  keys: 


PiC  :  client.  \ 

j  VA  :  ts  .  ■  M  3k  :  shKe  C  A  \(k)  I 

\Ve  :  etype  .  / 

We  have  the  following  message  generation  rule: 

(  •  3m  :  msg  l(m)) 

Note  that  MG  does  not  allow  I  to  generate  the  dbK  of  a 
principal  since  dbK  A  is  never  a  subtype  of  msg.  Note  also 
that  although  the  intruder  may  generate  fresh  messages,  he 
may  not  type  these  as  anything  other  than  msg.  The  intruder 
is  not  allowed  to  generate  any  other  kind  of  data,  not  princi¬ 
pal  names  of  any  kind  (the  introduction  of  new  agents  hap¬ 
pens  out-of-band),  not  long-term  keys  (they  are  distributed 
out-of-band),  and  not  timestamps  (they  are  generated  by  an 
external  clock,  not  by  any  principal).  Allowing  the  intruder 
to  generate  data  of  these  forms  is  incorrect  since  it  would 
open  the  doors  to  countless  false  attacks. 

6.3  Data  Access  Rules 

The  intruder  is  entitled  to  look  up  the  same  data  as  any 
other  principal.  It  can  however  store  intercepted  data  in  the 


Ve  :  etype  . 

Vk  :  dbK  I. 


I 


No  other  piece  of  information  is  accessible  out  of  thin  air 
by  the  intruder:  Unless  he  has  intercepted  this  information 
otherwise,  he  should  not  be  able  to  guess  the  nonces  gener¬ 
ated  by  other  principals,  keys  that  do  not  belong  to  him,  and 
clearly  generic  messages. 


7  Abstract  Level  Anomalous  Behavior 


One  of  the  most  notorious  differences  between  versions 
4  and  5  of  Kerberos  is  the  manner  the  KAS  and  the  TGS 
transmit  the  ticket-granting  and  service  tickets,  respectively. 
In  Kerberos  4,  the  client  receives  these  tickets  as  part  of  the 
data  encrypted  under  either  her  dbK  or  a  shK  she  knows.  We 
saw  that  version  5  sends  the  tickets  as  a  separate  component. 
Thus  it  seems  possible  for  the  intruder  to  take  advantage  of 
this  new  message  structure  and  tamper  with  the  unprotected 
ticket.  A  specific  example  of  such  a  scenario  is  as  follows. 

C  sends  a  request  for  credentials  to  K  using  the 
rule  ai.i-  K  sees  the  network  message  C,T,n\ 
and  replies  using  rule  0:2.1.  sending  the  network 
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message  C,  TGT,  {AKey, n\,T{kc  where  TGT  = 
{AKey,C}kT  is  the  ticket  granting  ticket.  The  intruder  I 
reads  this  message  from  the  network  using  INT  and  creates 
a  new  message  X  using  MG.  I  then  creates  (using  DMC, 
DMC,  CMP,  CMP)  the  message  C,  X,  { AKey ,  m,T}ko, 
i.e.,  K’ s  message  with  the  ticket  TGT  for  T  replaced 
by  the  freshly  generated  message  X ,  and  puts  it  on  the 
network  using  TRN.  C  now  sees  the  network  message 
C,  X ,  {AKey,  n\,T}kc,  which  is  of  the  form  she  expects 
(she  does  not  expect  to  be  able  to  read  the  ticket,  and  so 
does  not  know  that  it  has  been  replaced  by  X).  She  thus 
completes  the  Authentication  Service  Exchange  by  tiring 
rule  cti.2,  storing  X,  m,  T,  and  AKey  in  the  memory  pred¬ 
icate  Authc- 

Believing  she  has  obtained  credentials  for  T,  C  now 
initiates  the  Ticket  Granting  Exchange  with  T.  She  uses 
the  Authc  memory  predicate  to  fire  rule  0:3.1  and  send 
the  network  message  X,  {C}AKey,  S,  n2-  When  I  sees 
this  message  on  the  network  he  removes  the  message  from 
the  network  (INT).  He  then  generates  a  new  message 
TGT,  {C}AKey,  S,ri2  by  replacing  X  with  the  original 
ticket  TGT  (DMC,  CMP).  I  then  puts  this  message  onto 
the  network  (TRN).  Finally,  T  sees  the  network  message 
TGT,  {C}AKey,  S,  n2  and  uses  this  to  fire  the  rule  0:4.1, 
granting  C’s  apparent  request  for  credentials  for  use  with 
S. 

As  a  result,  T  has  fired  rule  04.1  based  on  the  network 
message  {AKey,  C}kr,  {C}AKey,  C,  S,  n2  even  though  C 
never  sent  this  message.  This  does  not  appear  to  provide 
an  attack  against  keys,  but  it  does  give  a  counterexample 
to  the  direct  translation  of  a  property  of  Kerberos  4:  when 
Theorem  6.22  of  [1]  is  translated  to  this  formalization  of  the 
new  version  of  Kerberos,  it  becomes  the  following. 

Violated  Property  1.  For  C  client,  T  TGS, 

AKey  :  shK  C  T,  kr  :  dbK  T,  S  :  server,  and 
n2  :  nonce,  if  {C}AKey  and  {AKey,C}kT  have  ap¬ 
peared  on  the  network  (possibly  encrypted ),  and  I  does 
not  have  access  to  AKey,  then  C  put  the  message 
{AKey,  C}kT,  {C}AKey,  C,  S,  n2  on  the  network. 

As  our  example  shows,  this  property  does  not  hold  in 
our  abstract  formalization  of  Kerberos  5;  as  noted  be¬ 
low  in  Sec.  11,  it  does  not  hold  for  our  detailed  formal¬ 
ization  either.  It  was  possible  for  it  to  hold  for  Ker¬ 
beros  4  because  the  message  in  that  protocol  sent  from 
K  to  C  was  the  equivalent  of  (after  dropping  timestamps) 
{AKey,T,  TGT}kc.  This  includes  the  ticket  for  T  in  the 
encryption  under  kc  :  dbK  C,  unlike  the  KRB_AS  JtEP  mes¬ 
sage  C,  TGT ,  {AKey, ni,T}kc,  preventing  the  intruder 
from  replacing  it  with  any  other  message  before  it  reaches 
C.  The  above  comments  show  that  this  anomaly  also  vi¬ 
olates  the  translation  of  another  theorem,  proved  for  Ker¬ 
beros  4,  in  [2] . 


Violated  Property  2.  For  C  :  client,  T  :  TGS,  Y  :  msg, 
AKey  :  shK  C  T,  n\  :  nonce,  kc  ■  dbK  C,  and  kr  : 
dbK  T,  if  C,Y,{AKey,n\,T}kc  appears  on  the  network 
and  I  does  not  have  access  to  kc,  then  Y  =  {AKey,  C}kT 
and  T put  the  message  C,  {AKey,  C}kT,  {AKey,  n\,  t}kc 
on  the  netw’ork. 

Note  that  the  intruder  may  do  the  same  thing  with  the 
KRELTGS_REP  message  (instead  of  the  KRB_AS  JtEP  message 
as  described  above),  replacing  the  ticket  for  S  with  an  arbi¬ 
trary  bit-string  and  then  reversing  the  switch  when  C  sends 
a  KRB_AP_REQ  message  to  S.  Such  a  switch  shows  that  the 
translation  of  Theorem  6.23  of  1 1]  also  fails  for  Kerberos  5 
for  similar  structural  reasons,  as  does  a  corresponding  the¬ 
orem  in  [2] . 

We  believe  that  the  attack  found  by  Mitchell,  Mitchell, 
and  Stern  [9]  on  a  simplified  version  of  Kerberos  5  does 
not  appear  in  our  formalization  because  in  their  encoding 
the  KRB_TGS_REP  message  from  T  to  C  did  not  include  S 
encrypted  under  AKey. 

8  Abstract  Level  Protocol  Verification  using 
Rank  and  Corank 

8.1  Authentication  in  the  TGS  Exchange 

In  this  section  we  state  and  outline  the  proof  of  an  au¬ 
thentication  theorem  that  we  were  able  to  prove  using  the 
ideas  of  rank  and  corank.  Although  we  have  not  directly  for¬ 
mulated  it,  there  is  some  measure  of  confidentiality  implicit 
in  the  proof  of  this  theorem  as  we  show  that  the  intruder 
does  not  know  AKey.  Note  that  keys  are  not  intentionally 
leaked  to  the  intruder  after  some  period  of  time  as  they  are 
in  [1,2,  3], 

The  authentication  theorem  which  we  include  is  intended 
to  capture  authentication  of  the  client  C  to  the  TGS  T,  in  the 
form  of  data  origin  authentication.  The  theorem  states  that, 
given  a  few  assumptions,  if  T  grants  credentials  to  C  for  use 
with  S  on  the  basis  of  some  ticket  and  authenticator,  then 
the  ticket  originated  with  some  I\  :  KAS  and  was  generated 
by  K's  firing  of  a  certain  MSR  rule  to  grant  C  credentials 
for  use  with  T.  Furthermore,  the  authenticator  originated 
with  C  and  was  generated  by  C’s  firing  of  another  specified 
MSR  rule  to  request  credentials  for  some  S'  :  server  from 
T,  and  this  was  fired  after  K  fired  its  rule.  The  assump¬ 
tions  required  for  this  conclusion  are  that  the  intruder  does 
not  have  access  to  the  database  keys  of  C  and  T  which  are 
used  in  the  messages  under  consideration  and  that  the  au¬ 
thenticator  and  ticket  did  not  exist  in  the  initial  state  of  the 
trace.  This  theorem  appears  to  be  the  appropriate  weaken¬ 
ing  of  the  property  of  Kerberos  4  which  is  violated  by  the 
anomaly  discussed  above;  in  particular,  the  theorem  does 
not  state  that  C  sent  the  ticket  and  authenticator  together. 
Formally,  we  have  the  following. 
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Theorem  1.  For  C  :  client,  T  :  TGS,  C,T  ^  I, 
S  :  server,  kc  '■  dbK  C,  kr  :  dbK  T,  AKey  : 
shK  C  T,  and  n 2  :  nonce,  if  the  beginning  state  of  a 
finite  trace  does  not  contain  l(fcc),  I (&t)>  or  any  fact 
F  with  PkT{F\  AKey,  C)  >  0  or  pAKey{F;C )  >  0, 
and  at  some  point  in  the  trace  T  fires  rule  014.1,  consum¬ 
ing  the  fact  N({AKey,C}kT,{C}AKey,C,S,n2),  then 
earlier  in  the  trace,  some  K  :  KAS  fired  rule  a2.i, 
existentially  generating  AKey  and  producing  the  fact 
N (C,  {AKey,  C}kT,  {AKey,  n,T}k,)  for  some  n  :  nonce 
and  k!  :  dbK  C.  Also,  after  K  fired  this  rule  and  before 
T  fired  the  rule  in  the  hypothesis,  C  fired  rule  <23.1  to  cre¬ 
ate  the  fact  N(X,  {C}AKey,  C,  S',  n')  for  some  X  :  msg, 
S'  :  server,  and  n'  :  nonce. 

In  order  to  show  that  the  ticket  {AKey,  C}kr  origi¬ 
nates  with  I\,  we  consider  the  fc^-rank  of  facts  relative  to 
AKey,  C.  By  hypothesis  this  rank  is  not  positive  for  any 
fact  at  the  beginning  of  the  trace.  A  few  straightforward 
lemmas,  proved  by  inspection  of  the  MSR  rules  and  the  hy¬ 
pothesis  that  the  intruder  does  not  know  kr  at  the  beginning 
of  the  trace,  show  that  K  may  create  the  ticket  and  that  nei¬ 
ther  any  other  honest  principal  nor  the  intruder  could  have 
created  it.  In  order  to  show  that  the  authenticator  {C}  iKey 
originates  with  C,  we  consider  the  .4  /fey-rank  of  facts  rel¬ 
ative  to  C.  A  number  of  lemmas  show  that  the  authenti¬ 
cator  cannot  originate  with  an  honest  principal  other  than 
C.  Further  lemmas  and  an  argument  based  on  {kc,  kr}- 
corank  relative  to  AKey  show  show  that  the  intruder  cannot 
generate  the  authenticator.  A  lemma  connecting  existential 
generation  of  keys  to  rank  shows  that  C  generated  the  au¬ 
thenticator  after  K  generated  the  ticket. 

We  expect  that  this  theorem  should  lift  to  the  more  de¬ 
tailed  formalization  fairly  easily  and  that  similar  techniques 
can  be  used  to  prove  other  authentication  properties. 

9  Detailed  Level  Protocol  Formalization 

Our  more  detailed  formalization  is  closer  to  the  version 
of  Kerberos  5  specified  in  [10]  than  is  the  abstract  level.  We 
have  formalized  the  option  (in  the  field  of  type  TOpt)  which 
allows  the  client  to  request  an  anonymous  ticket  from  T 
(Sec.  9.2)  and  the  message  field  (of  type  etype)  which  al¬ 
lows  the  client  to  request  a  particular  encryption  method, 
and  noted  anomalies  involving  both  of  these  details.  Mes¬ 
sage  digests  now  appear  as  specified  in  the  protocol;  we  are 
investigating  their  utility  in  avoiding  the  anomalies  we  dis¬ 
cuss  here.  We  have  added  the  message  field  (of  type  SOpt) 
which  allows  C  to  specify  whether  a  KRELAP_REP  response 
from  S  is  requested  (Sec.  9.3)  and  have  also  incorporated 
error  messages.  These  will  allow  investigation  of  proto¬ 
col  runs  which  would  not  appear  in  the  previous  analyses 
of  Kerberos.  The  authenticators  sent  to  T  and  S  now  in¬ 


clude  the  timestamps  tc.Treq  and  tc.Sreq  so  that  error  mes¬ 
sages  may  be  associated  with  their  corresponding  requests, 
although  we  have  not  added  any  temporal  checks.  Although 
we  do  not  make  use  of  it,  we  have  also  added  the  option  field 
of  type  KOpt  to  parallel  those  of  types  TOpt  and  SOpt  and 
various  flag  fields  corresponding  to  the  option  fields  already 
discussed. 

When  we  refer  to  Figs.  5 — 10,  we  now  mean  the  entire 
figure,  including  the  grayed-out  portions.  Figs.  11  and  12 
are  grayed-out  entirely  to  represent  the  fact  that  they  do  not 
appear  in  the  abstract  level  formalization  at  all,  but  do  ap¬ 
pear  here.  When  we  refer  to  a  detailed  level  rule  by  name 
we  will  now  use  5  with  an  appropriate  subscript  as  given  in 
the  various  figures;  this  will  mean  the  entire  rule  depicted  in 
the  figure,  including  the  grayed-out  portions.  While  fields 
specifying  encryption  type  appear  in  several  messages  in 
this  level,  and  should  technically  appear  for  every  encrypted 
message  that  occurs  (according  to  Sec.  3),  we  make  the  con¬ 
vention  that  we  will  omit  the  etype  in  this  capacity  unless 
we  are  explicitly  discussing  it  (as  in  Sec.  1 1.2). 

9.1  Authentication  Service  Exchange 

The  client’s  actions  in  this  exchange  are  formalized  in 
Fig.  5.  As  in  the  abstract  formalization,  in  rule  (q.i  C  asks 
K  for  credentials  for  the  server  T.  She  may  additionally 
request  the  issued  ticket  to  support  options  KOpts  and  the 
KAS  to  use  an  encryption  method  e. 

Rule  <5i.2  allows  C  to  process  the  KRB_AS_REP  message 
which  K  sends  in  response  to  her  initial  request.  The  ex¬ 
pected  form  of  this  reply  is  exactly  like  that  in  the  abstract 
formalization,  with  the  addition  of  the  TFlags  field  in  the 
part  encrypted  under  kc-  This  field  contains  the  KOpts 
which  were  both  requested  by  C  and  granted  by  I\;  we  do 
not  explicitly  consider  any  specific  TFlags  in  our  formal¬ 
ization. 

Rule  Si. 2 '  shows  C’ s  error  processing  of  a  generic  er¬ 
ror  message,  formalized  by  C  storing  relevant  information 
in  the  memory  predicate  ASErrorc-  The  ErrorCode 
describes  the  reason  why  the  KRB_AS_REQ  failed;  see 
Sec.  8.3  of  [10]  for  a  complete  and  current  list  of  possible 
ErrorCode  s. 

The  actions  of  the  KAS  K  are  formalized  in  Fig.  6. 
Rule  S2A  is  similar  to  rule  a2A,  except  K  also  checks  the 
validity  of  KOpts  and  e.  We  represent  the  process  of  deter¬ 
mining  which  KOpts  are  to  be  granted  and  set  in  TFlags 
by  the  SetAuthFlags  external  process. 

If  C’s  request  is  not  valid  for  any  reason  (as  determined 
by  the  external  process  Invalid ),  then  K  reads  the  current 
time  t-K.err  from  the  local  clock  via  the  external  process 
ClockK-  When  rule  S2. i>  is  fired,  K  sends  an  error  message 
consisting  of  the  time  the  error  occurred  (f/cjerr)  and  the 
appropriate  ErrorCode,  along  with  the  names  C  and  K. 
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9.2  The  Ticket-Granting  Exchange 

The  client’s  actions  in  this  exchange  are  formalized  in 
Fig.  7.  Rule  $3.1  fires  like  rule  0:3.1 ,  but  C  also  includes 
the  current  time  tc,Treq  (obtained  via  the  external  process 
Clockc ),  a  message  digest,  keyed  by  AKey,  of  the  un¬ 
encrypted  portion  of  the  KRB_TGS_REQ,  along  with  TOpts 
and  the  etype  e.  Recall  that  the  only  one  of  many  possible 
TOpts  that  we  will  explicitly  consider  is  a  request  for  an 
anonymous  service  ticket. 

The  client’s  second  rule,  (S3  2,  allows  her  to  read  from 
the  network  a  KRB_TGS_REP  message  that  matches  her  re¬ 
quest  to  T.  It  is  exactly  analogous  to  rule  81.2-  Note  that  if 
anonymous  is  one  of  the  TFIags  sent  by  T,  then  instead  of 
the  name  C  the  dummy  identifier  user  will  appear  in  the 
ticket  Y  in  rule 

Rule  83  2'  allows  for  C’ s  processing  of  error  messages  in 
exactly  the  same  manner  as  rule  8 1.2'.  Note  that  the  names 
C  and  T  in  the  error  message  must  match  those  in  the  role 
state  predicate  L. 

Fig.  8  shows  the  actions  of  the  TGS  T  in  the  ticket  grant¬ 
ing  exchange.  If  C’s  request  is  valid  (as  determined  by  the 
V alid  external  process)  and  the  checksum  ck  sent  by  C  is 
of  the  correct  form,  then  T  uses  the  SetServFlags  exter¬ 
nal  process  to  determine  which  SFIags  will  be  set,  and  fires 
rule  84.1 .  We  again  note  that  if  anonymous  is  requested  by 
C  in  the  TOpts  field  and  granted  by  T  (that  is,  it  appears  in 
the  SFIags  field  sent  in  the  KRB_TGS_REP)  then  T  will  send 
the  generic  name  user  in  place  of  C  in  the  ticket. 

Rule  8441  exactly  parallels  K’s  sending  of  error  mes¬ 
sages  in  Sec.  9.1.  Note  that  the  Invalid  external  process 
encompasses  the  possibility  that  the  checksum  ck  sent  in 
the  authenticator  is  not  the  expected  message  digest.  Of 
course,  the  Invalid  predicate  can  indicate  rejection  of  a  re¬ 
quest  from  C  for  a  number  of  other  reasons. 

9.3  The  Client/Server  Authentication  Exchange 


Since  the 

message 

flow 

in  this  exchange 

de- 

pends  upon 

whether 

the 

MUTUAL.REQUIRED 

or 

MUTUAL_NON_REQUIRED 

SOpt 

is  requested  in 

the 

KRB_AP_REQ,  we  have  subdivided  this  exchange 
into  these  two  cases.  The  mutual_required 
/mutual_non_required  option  is  the  only  one  of  the 
possible  SOpts  we  explicitly  consider  in  this  exchange. 

9.3.1  Mutual  Authentication  Required 

Fig.  9  shows  the  role  of  the  client  C  in  this  ex¬ 
change.  Rule  (j.5.1  is  the  obvious  extension  of  rule  0:5.1; 
here  we  use  the  constraint  Mutual  to  indicate  that  the 
mutual  .required  option  is  being  requested  by  C.  Note 
that  if  the  ticket  Y  stored  in  the  Serviced — )  predicate  is 


anonymous  (indicated  by  the  presence  of  anonymous  in 
the  SFIags  field,  also  stored  in  Serviced — ))>  then  C  will 
send  the  generic  identifier  user  in  place  of  her  name  in  the 
authenticator  sent  in  rule  $51 .  We  denote  the  message  di¬ 
gest  here  by  [. .  • ]sKey  because  [10]  specifies  that  this  op¬ 
tional  checksum  is  “application  specific.” 

Rule  £5.2  is  virtually  identical  to  rule  05.2,  the  only  dif¬ 
ference  being  the  presence  of  SOpts  in  the  role  state  predi¬ 
cate  L. 

Rule  S5.2'  models  C’s  handling  of  error  messages  in  ex¬ 
actly  the  same  way  as  in  the  previous  exchanges  with  KAS 
and  TGS,  with  C  storing  relevant  information  sent  in  the 
error  message  in  the  AP Error  memory  predicate. 

The  server’s  role  in  this  exchange  is  given  in  Fig.  10. 
Rule  $61  formalizes  S' s  reply  (because  mutual  authentica¬ 
tion  is  requested  by  C,  as  indicated  again  by  the  Mutual 
constraint)  to  a  valid  KRB_AP_REQ.  Here  S  checks  that  the 
message  digest  ck  sent  by  C  is  the  appropriate  application 
specific  message  digest,  just  as  T  does  in  the  Ticket  Grant¬ 
ing  Exchange. 

Rule  $6.1'  models  S  sending  error  messages  just  as  in  the 
Ticket  Granting  Exchange. 

9.3.2  Mutual  Authentication  Not  Required 

This  exchange  (shown  in  Figs.  11  and  12)  is  very  simi¬ 
lar  to  the  previous  one,  except  C  does  not  require  a  re¬ 
sponse  from  S  (denoted  by  the  NoMutual(SOpts)  con¬ 
straint).  Upon  sending  the  initial  application  request  to  S,  C 
stores  S,  SKey  in  the  DoneNoMut  predicate,  in  rule  $sm. 
The  remarks  above  about  C’s  use  of  an  anonymous  service 
ticket  hold  here  as  well. 

When  S  receives  the  request  he  sends  no  response,  pro¬ 
vided  the  request  is  valid  (as  determined  by  the  external 
process  Valid).  In  this  case  S  fires  rule  $6M,  storing 
C,  SKey,  tc,Sreq  in  the  Meins  predicate. 

The  handling  of  error  messages  for  both  C  and  S 
(rules  $5'. 2'  and  $6'.u)  is  virtually  identical  to  the  Mutual 
Authentication  Required  case. 

10  Detailed  Level  Intruder  Formalization 

The  admissible  Dolev-Yao  intruder  actions  are  updated 
to  reflect  the  above  changes  and  additions  to  the  syntax  of 
the  MSR  specification. 

The  intruder  rules  for  interception/transmission,  de¬ 
composition/composition,  and  decryption/encryption  with  a 
known  key  change  only  to  the  extent  that  we  must  take  en¬ 
cryption  types  into  account  in  the  rules  that  involve  crypto¬ 
graphic  primitives.  There  is  no  disassembling  rule  for  mes¬ 
sage  digests  since  (cryptographic)  hashing  does  not  permit 
recovering  a  message.  However,  the  intruder  can  construct 
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Figure  11.  The  client’s  role  in  the  Client/Server  Exchange  without  mutual  authentication. 
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Figure  12.  The  end  server’s  role  in  the  Client/Server  Exchange  without  mutual  authentication. 


a  message  digest  as  long  as  he  knows  the  proper  key. 
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(V/:  Flag.  •  !(/))’ 

Observe  that,  by  virtue  of  subtyping,  the  last  two  inference 
figures  apply  to  each  of  the  subsorts  of  Opt  and  Flag. 

Other  information  that  was  inaccessible  in  the  abstract 
specification  of  the  intruder  remains  inaccessible. 


The  updates  to  the  generation  rules  are  limited  to  allow¬ 
ing  the  intruder  to  choose  the  encryption  type  of  any  session 
key  he  may  generate.  None  of  the  new  data  types  intro¬ 
duced  at  this  level  of  detail  can  be  generated  by  the  intruder 
(or  any  other  principal).  Therefore  there  are  no  additional 
data  generation  rules  with  respect  to  what  we  presented  in 
Section  6.2. 

Data  access  rules  are  subject  to  similar  changes.  How¬ 
ever,  the  new  data  types,  encryption  types,  options  and  flags, 
shall  be  treated  similarly  to  timestamps:  each  of  them  range 
over  a  limited  number  of  legal  values,  each  being  public 
knowledge.  As  for  timestamps,  these  rules  make  encryp¬ 
tion  types,  options  and  flags  guessable. 


(Ve  :  etype. 

•  1(e))' 

(Vo  :  Opt. 

^  l(o))' 

11  Detailed  Level  Anomalous  Behavior 

We  now  discuss  two  anomalies  that  we  have  discovered 
in  our  detailed  formalization  of  Kerberos  5  which  are  not 
present  in  the  abstract  level.  Both  take  advantage  of  addi¬ 
tional  fields  not  included  in  our  abstract  formalization.  The 
first  anomaly  we  discuss  in  an  analogue  of  that  in  Sec.  7, 
making  use  of  new  options  available  here.  The  second 
anomaly  we  discuss  is  completely  unrelated  to  the  others, 
as  it  exploits  the  encryption  type  field  e  send  by  C  in  the 
KRB.AS.REQ. 

We  note  that  the  anomaly  discussed  in  Sec.  7  also  ap¬ 
pears  in  this  formalization.  It  is  not  prevented  by  the  check¬ 
sum  sent  by  C  in  the  KRB_TGS_REQ  message  as  we  have 
formalized  it  (taken  over  TOpts,  C,  S,  11,2,  e ).  The  anomaly 
appears  to  be  fixed  if  the  ticket-granting  ticket  (or  what  C 
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thinks  is  the  TGT )  is  also  included  in  the  above  checksum, 
although  this  remains  to  be  proved. 

11.1  Anonymous  Ticket  Switch  Anomaly 

In  this  scenario  we  make  no  explicit  assumptions 
about  the  application  specific  checksums  C  sends  in  the 
KRB_AP_REQ  messages,  only  that  they  agree  with  the  local 
policy  of  the  server  S.  It  begins  with  a  normal  AS  exchange, 
after  which  C  has  a  ticket  X  for  use  with  a  T GS,  the  name 
T  of  the  TGS,  and  the  corresponding  shK  C  T  AKey  all 
stored  in  the  memory  predicate  Awthc- 

Now  C  desires  two  tickets  from  the  TGS  T  for  the 
same  server  S,  one  a  non-anonymous  and  the  other 
an  anonymous  ticket.  She  fires  rule  S3 1  twice  and  T 
responds  as  expected  by  firing  rule  6,\ .  1  twice,  sending 
C,  Y, ,  Z\  and  C,Y2,Z2  (where  Y\  is  the  non-anonymous 
ticket  {SKey1,C}ks,  Zx  =  {SKeyi,  m,  S}AKey,  Y2  is 
the  anonymous  ticket  {anonymous,  SKey2,  USER}fcg,  and 
Z2  =  {SKey2,n2,ANONYMOUS,S}AKey).  At  this  point 
the  intruder  I  intervenes  (firing  rules  INT,  INT,  DCM, 
DCM,  CMP,  CMP,  TRN,  and  TRN)  and  switches  the 
tickets  in  the  two  KRELTGS_REP  messages,  putting  C,  Y[ .  Z2 
and  C,  Y2,  Z\  on  the  network.  C  has  no  reason  to  suspect 
that  anything  is  wrong  with  these  two  altered  messages,  so 
she  fires  rule  (>3.2  twice,  storing  Y\,  anonymous,  S,  SKey2 
in  a  memory  predicate  Servicec,  1  and  >2,  S,  SKeyi  in 
Servicec, 2-  At  this  point  C  wrongly  thinks  that  Y-\  is  an 
anonymous  ticket  and  Y2  in  an  ordinary  ticket,  although 
she  does  correctly  consider  SKey2  to  be  an  “anonymous 
key”,  and  SKeyi  a  “non-anonymous  key”. 

C  then  contacts  S  using  the  tickets  obtained  in  the 
Ticket  Granting  Exchange  without  requiring  mutual  au¬ 
thentication  from  S.  Thus  she  fires  rule  S-/  1  twice, 
putting  the  messages  mutual_non_required,  Yi,  Auth2 
and  mutual_non_required,  Y2,  Authi  on  the  network 
(where  Authi  =  {C,  cks,2,  tc,Sreq2}  SKeVl  and  Authi  = 
{C,cks,i1tc,Sreqi}sKey2)-  These  requests  will  not  be 
processed  unless  the  intruder  I  intervenes  again  since  the 
key  inside  of  Yi  will  not  decrypt  the  authenticator  Auth2, 
and  the  key  inside  Y2  will  not  decrypt  Authi ■  Thus 
I  fires  some  rules  (namely  INT,  INT,  DCM,  DCM, 
CMP,  CMP,  TRN,  and  TRN  again),  and  takes  the 
pair  of  messages  mutualjnonjrequired,  Yi,  Auth2  and 
mutual_non_required,  Y2l  Authi  from  the  network  and 
replaces  them  with  mutual_non_required,  Ij ,  Authi  and 
mutual_non_required,  Y2,  Authi,  note  that  both  use 
Authi.  Then  S  receives  the  first  of  these  messages,  de¬ 
crypts  Y\  and  finds  SKeyi, C  inside,  uses  this  key  to 
decrypt  Authi  and  finds  C,  cks,2,tc,Sreq2  inside,  then 
fires  rule  Squi  and  stores  C,  SKeyi,  tc,Sreq2  in  the  mem¬ 
ory  predicate  Mems ■  S  then  decrypts  Y2  and  finds 
anonymous,  SKey2,  user  inside  and  attempts  to  decrypt 


Authi  using  SI\ey2 ,  but  is  unable  to  do  so.  In  our 
present  formalization,  S  does  not  do  anything  in  response 
to  an  unreadable  authenticator.  However,  a  natural  ana¬ 
logue  of  rule  Squv  allows  S  to  put  the  error  message 
KRELERROR,  ts.err,  ErrorCode,  USER,  S  on  the  network 
(omitting  the  unreadable  authenticator  timestamp  tc,Sreq2)- 
I  intercepts  this  message  (using  INT),  replaces  user  with 
C  (using  DMC  and  CMP),  and  transmits  this  modified 
error  message  to  C  (using  TRN).  C  processes  this  error 
and  thus  believes  that  her  non-anonymous  request  was  re¬ 
jected  and  her  anonymous  request  was  accepted.  This  sit¬ 
uation  is  undesirable  since  C  believes  she  has  completed 
an  anonymous  exchange  with  S  and  that  she  has  not  com¬ 
pleted  any  exchange  in  which  her  identity  has  been  received 
by  S. 

This  anomaly  violates  properties  proved  by  Bella  and 
Paulson  in  [1,  2]  for  Kerberos  4,  which  are  analogues  for  the 
Client/Server  Authentication  Exchange  of  Violated  Proper¬ 
ties  1  and  2  in  Sec.  7.  This  anomaly  seems  to  be  avoided  if 
the  checksums  in  the  KRB_AP_REQ  messages  are  also  taken 
over  the  service  ticket  (so  that  the  server  S  would  be  aware 
of  any  ticket  switches),  but  this  is  also  yet  to  be  proved. 

11.2  Encryption  Type  Anomaly 

This  anomaly  involves  the  following  scenario.  Since  dif¬ 
ferent  encryption  methods  can  require  different  keys  which 
are  not  interchangeable,  suppose  that  C  has  a  database  key 
he,  1  which  is  used  for  encryption  of  type  el  and  which  has 
been  compromised  in  some  way,  and  a  second  database  key 
kc, 2  for  encryption  of  type  e2  which  is  still  secure.  Further 
suppose  that  the  loss  of  kcj  has  not  yet  been  reported  to 
the  KAS.  Now  C  wants  to  obtain  a  ticket  granting  ticket  for 
use  with  a  TGS  T,  and  she  wants  the  response  encrypted 
using  e2  so  that  the  uncompromised  key  kc,2  will  be  used. 
Thus  she  fires  rule  <5-|  1 ,  putting  C,  T,  n,  e2  on  the  network 
(here  we  assume  that  KOpts  is  empty  and  thus  ignore  it).  I 
intervenes,  firing  rules  INT,  DMC,  and  CMP,  and  replaces 
the  message  C  sent  with  C,  T,  n,  el.  K  sees  this  altered 
request  as  a  legitimate  message  and  fires  rule  S2.i,  placing 
C,  X,  {AKey,  n,  T}f}  i  on  the  network,  where  X  is  the 
ticket  granting  ticket  {AKey,  C}kT  for  use  with  T.  I  inter¬ 
cepts  the  KRB_AS_REP  with  rule  INT,  storing  it  in  a  memory 
predicate.  Finally,  I  can  fire  rule  DCC'  to  decrypt  the  con¬ 
tents  of  {AKey,  n,  T}f}  i,  obtaining  AKey.  This  allows 
the  intruder  to  masquerade  as  C  not  only  using  the  compro¬ 
mised  key  kc,  1,  but  also  when  C  attempts  to  use  the  un¬ 
compromised  key  kc, 2  by  requesting  the  “safe”  encryption 
type  e2. 

Note  that  this  anomaly  is  not  fixed  by  the  checksum 
that  C  can  send  with  the  KRB_AS_REQ  message  (which 
we  do  not  include  in  our  formalizations,  but  is  described 
in  [10]  as  optional),  keyed  with  a  dbK  C,  as  the  follow- 
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ing  scenario  shows.  C  puts  C,  T,  n,  e2,  [C,  T,  n,  e2]^  2 
on  the  network  and  I  intervenes,  replacing  it  with 
C,T,  n,  el,  [C,  T,n,  (which  I  can  do,  since  the  hash 

is  public  and  she  knows  kc,  1  and  el).  Then  the  action  con¬ 
tinues  as  above,  with  I  gaining  knowledge  of  AKey. 

12  Conclusions  and  Future  Work 

In  this  paper,  we  have  specified  Kerberos  5  at  two  levels 
of  detail  using  the  Multiset  Rewriting  (MSR)  framework. 
The  abstract  formalization  exhibits  anomalous  behavior  not 
seen  in  Kerberos  4,  and  we  prove  an  appropriately  weak¬ 
ened  authentication  property  that  still  holds.  We  do  this 
using  notions  of  rank  and  corank  which  were  inspired  by 
the  work  of  Schneider  [11].  The  detailed  formalization  is 
closer  to  the  full  protocol  as  given  in  [8,  10]  and  exhibits 
both  the  anomaly  seen  at  the  abstract  level  and  additional 
anomalous  behavior  related  to  the  added  detail.  It  appears 
that  some  of  these  anomalies  may  be  resolved  through  the 
use  of  cryptographic  checksums,  but  we  did  not  yet  prove 
this  formally. 

MSR  proved  to  be  an  adequate  language  in  this  effort 
and  only  minor  adaptations  were  needed.  This  work  also 
gave  some  preliminary  insight  into  possible  approaches  to 
reasoning  on  an  MSR  specification. 

This  work  is  part  of  a  larger  project  aimed  at  formalizing 
of  Kerberos  5  at  various  levels  of  details,  with  the  ultimate 
goal  of  capturing  all  the  facets  of  this  complex  protocol 
suite  [10].  Future  additions  include  more  timestamps  and 
temporal  checks,  explicit  consideration  of  all  options  spec¬ 
ified  in  [8]  (in  particular  renewable  or  postdatable  tickets), 
and  the  formalization  of  the  other  available  subprotocols. 
As  we  proceed,  we  intend  to  state  and  prove  security  prop¬ 
erties  in  the  spirit  of  [11,  12],  in  particular  additional  au¬ 
thentication  properties  and  confidentiality  properties  which 
are  implicit  in  our  proofs  of  authentication.  We  also  hope 
to  consider,  and  precisely  state  in  our  eventual  full  report 
on  this  project,  the  connections  between  our  different  for¬ 
malizations  of  Kerberos  5;  one  connection  we  are  investi¬ 
gating  is  the  reuse  of  proofs  from  the  abstract  formalization 
as  skeletons  for  proofs  in  the  more  detailed  formalizations. 
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